Add configurable security context options for Postgres pods - #3224

Problem description

Postgres clusters cannot run in namespaces enforcing the Pod Security Standards restricted profile (Pod Security Admission, Kyverno, Gatekeeper, Azure Policy), even when Spilo already runs as a non-root user via spilo_runasuser. The profile requires fields the operator cannot emit:

The usual workaround is a mutating webhook, which makes the generated StatefulSet differ from the live one and causes a rolling update with a switchover on every sync (#1879, #3210).

Changes

New operator options (ConfigMap and OperatorConfiguration, kubernetes section), independent of spilo_runasuser:

How they are applied:

• Pod level (runAsNonRoot, seccomp): applies to all containers of the Spilo and logical backup pods, including init containers; a container can still override it in its own security context.
• Container level (dropped capabilities, allowPrivilegeEscalation: false, runAsNonRoot): filled into the Spilo, sidecar, init and logical backup containers only where the container does not define the field itself. Privileged containers are left untouched, and allowPrivilegeEscalation is not disabled for containers adding SYS_ADMIN (rejected by the API server).
• runAsNonRoot is set on both levels on purpose: webhooks enforcing it (e.g. Kyverno, Rolling update loop on every resync when a mutating admission webhook injects security context fields (e.g. runAsNonRoot) #3210) inject it into the containers too, so with only the pod field the generated StatefulSet would keep differing from the mutated one and the operator would roll the cluster on every sync.
• Containers and their security contexts are deep copied, so neither the cluster manifest nor the operator configuration is mutated.

spilo_run_as_non_root uses the name proposed in #3209. drop_pod_capabilities mirrors additional_pod_capabilities; happy to rename it to dropped_pod_capabilities as proposed in #2993 / #2244 if preferred.

All options are operator-wide, like spilo_privileged, spilo_allow_privilege_escalation and additional_pod_capabilities; only spiloRunAsUser / spiloRunAsGroup / spiloFSGroup exist per cluster. With spilo_run_as_non_root enabled, a cluster manifest overriding spiloRunAsUser with 0 fails to start its pods (documented). Per-cluster overrides of the security options (#3158, the spiloRunAsNonRoot field of #3209) are left to a follow-up covering all of them consistently.

Docs: parameter reference, a new "Pod Security Standards" section in administrator.md with a restricted recipe, chart values.yaml and sample manifests.

configuration:
  kubernetes:
    spilo_runasuser: 101
    spilo_runasgroup: 103   # primary group of postgres in Spilo, required for cron jobs
    spilo_fsgroup: 103
    spilo_run_as_non_root: true
    spilo_allow_privilege_escalation: false
    spilo_seccomp_profile: RuntimeDefault
    drop_pod_capabilities:
    - ALL

Upgrade impact

All new options are unset by default, so upgrading the operator does not change any pod template. Exception: setups that already set spilo_allow_privilege_escalation: false get allowPrivilegeEscalation: false on their sidecars and init containers too, which triggers one rolling update.

Cron, backups and certificate rotation without privilege escalation

The docs claimed spilo_allow_privilege_escalation is required by cron (#1730). This only holds when Spilo runs as root: as non-root, Spilo starts cron with LD_PRELOAD=cron_unprivileged.so (no-op seteuid/initgroups), so no setuid is needed. Verified with ghcr.io/zalando/spilo-18:4.1-p2 running as 101:103 with no-new-privileges, all capabilities dropped (CapBnd: 0) and the default seccomp profile: crontab -u postgres - installs the crontab and cron executes the jobs. Only Spilo's optional renice job is skipped (Spilo logs it). Note that spilo_runasgroup must be 103: with the crontab group (101) cron silently fails to run jobs. The spilo_allow_privilege_escalation docs were updated accordingly.

Linked issues

Fixes #2081 — runAsNonRoot on the Postgres StatefulSet
Fixes #2291 — allowPrivilegeEscalation: false for the exporter sidecar (with spilo_allow_privilege_escalation: false)
Fixes #3210 — rolling update loop when a webhook injects runAsNonRoot (configure the same value with spilo_run_as_non_root; webhooks injecting fields the operator has no option for, e.g. sysctls #3095, still diverge)

Addressed for Spilo and logical backup pods:

• Support for Pod Security Admission  #1745 Support for Pod Security Admission
• Feature Request: Non-Privilege-Escalation Support for Certificate Rotation & Backups #1730 Non-privilege-escalation support for certificate rotation & backups (works when running as non-root, see above)
• Custom Security Context in postgresql #2223 Custom Security Context in postgresql
• Set Security Context in postgresql manifest #1052 Set Security Context in postgresql manifest
• Support for securityContext #1879 Support for securityContext (webhook mutations no longer needed for these fields)
• SecurityContext configurations are missing for postgres-operator-ui and cluster configurations #2682 SecurityContext configurations missing for cluster configurations (cluster part)

Partially addressed:

• Issue: Add Pod Security Standards (PSA) Support to PostgreSQL CR Spec #3158 Add PSA support to the PostgreSQL CR spec — operator-level options only, no per-cluster manifest fields yet
• Feature: allow setting of security context for sidecar containers ( and more) #2800 Security context for sidecar containers — defaults are filled into sidecars, but no per-sidecar security context in the cluster manifest

Not covered: connection pooler (#1722, see #3105), operator UI (#2682), per-cluster overrides in the postgresql manifest.

Related pull requests

• Supersedes Add securityContext runAsNonRoot on Postgres Statefullset  #2082 (derives the settings from spilo_runasuser, not configurable; the operator Deployment hardening from that PR can be submitted separately)
• Supersedes Add spilo_run_as_non_root option to keep pod spec in sync with webhook-injected security context #3209 (spilo_run_as_non_root on pod and Spilo container level): same option name, applied to all containers including sidecars and init containers; its per-cluster spiloRunAsNonRoot field is not included (see above)
• Overlaps add dropped_pod_capabilities #2993 (dropped_pod_capabilities), Custom SecurityContext in Postgresql, OperatorConfiguration CRDs #2244 (seccomp profile, dropped capabilities, sidecar security context)
• Sidecar security context: Add support for SecurityContext in sidecar containers #2087, allow security context for sidecars #2317 (closed)
• Same diff-loop class with webhook-injected fields: feat: add pod_sysctls operator config option #3095 (pod_sysctls)
• Connection pooler security context: feat(pooler): make connection pooler security contexts configurable #3105
• Prior work: set AllowPrivilegeEscalation on container securityContext #1326, set allowPrivilegeEscalation for deployment templates #1328, Fix for AllowPrivilegeEscalation : issue-1403 #1412 (allowPrivilegeEscalation), configurable container capabilities #1336, Fix empty capabilities #1380 (configurable capabilities), Set user and group in security context #1083, Fix operator configs runasuser and runasgroup #1361, StatefulSet fsGroup config option to allow non-root spilo #531 (runAsUser / runAsGroup / fsGroup), Set securityContext for backup container #2117 (logical backup security context)

Checklist

• Unit tests: defaults leave the pod template unchanged; all options on Spilo, sidecar, init and logical backup containers; runAsNonRoot on pod and container level; container-defined fields win; privileged and SYS_ADMIN containers; cluster manifest and operator configuration not mutated; ConfigMap parsing and seccomp validation (invalid values fail validation and StatefulSet generation)
• CRD and deepcopy regenerated
• Docs, chart values and sample manifests updated

🤖 Generated with Claude Code